With the early development of computers, all processing capability was located at a single computer system. These early machines were massive structures using many vacuum tubes, the result of which was the generation of an enormous amount of heat, and an associated sensitivity to environment. With these massive structures, all processing was performed centrally at this main computer, owing to the substantial expense required for isolation and environmental control. While remote communications with a computer system were sometimes used, the use was extremely infrequent and necessarily limited owing to the poor communications capability available at the time. These limitations of the need for environmental control and lack of adequate communications capability each persisted for several decades.
Progress in the semiconductor industry, initially with compact calculators beginning shortly after 1970 and followed by much more concentrated and capable chips suitable for computers less than a decade later, diminished and has ultimately virtually eliminated the need for extensive environmental control. Likewise, communications equipment, protocols and bandwidth compression have opened up the ability for substantial remote communications that were inconceivable only a few years ago.
For years, essentially from the days of first deployment of desktop computing, when a problem was encountered with a system, a computer user would be forced to resort to verbal telephone support with the hardware manufacturer. The waiting queues for these technical support personnel were notoriously long, with on-hold waits longer than an hour commonplace. When the technical support personnel were contacted, then the user would have to work verbally with the technical support person, and the support personnel would have to rely upon the computer users accurately describing the status and events, and performing operations requested by the support personnel. This arrangement was clearly less than optimum, requiring many times the effort that would have been required for the support personnel or a technician to directly diagnose and resolve the problem. Nevertheless, heretofore there has been little available for rapidly diagnosing the source of problems.
Unfortunately, many of the same issues and challenges face software vendors as those outlined above with regard to hardware manufacturers. When a particular program is prepared, the preparation work is usually performed upon a single type of computer having a particular combination of software installed thereon. All too frequently, the code will unintentionally rely upon components or features, such as may be found in the operating system, BIOS, system components or the like, which may vary from computer to computer. These variations may be based upon the release date of the particular computer, the software available at that time, upgrades provided by other vendors at the time of installation of their software, and other factors. At the time of deployment of early versions of the software, commonly referred to as alpha or beta versions, many of the incompatibility issues with diverse computers are discovered. Unfortunately, heretofore there has been no efficient way to diagnose the incompatibility, nor to quickly test the computer or isolate the source of the problem. Help databases have been prepared where persons may look for similar problems. Nevertheless, the amount of time involved in isolating and diagnosing a problem is still enormous and a source of much waste in the industry.
Even during the development of the software, substantial testing must be done. As is known in the art of programming, while a change in one part of the source code may not be expected to have an effect elsewhere, all too frequently this expectation is incorrect. As a result, even the most minor changes require substantial testing and validation to ensure that the changes do not disrupt the performance of a program at any other point. Presently, many software companies employ persons specifically in the role of testing. These persons will be assigned the chore of interacting with the computer as though they were a regular user, trying out each of the functions and determining whether any bugs may be identified. This approach also requires substantial operation by testing personnel, and is somewhat unreliable owing to the difficulty in determining whether the testers are, in fact, completing the testing properly and thoroughly. Nevertheless, this approach still provides cost saving over discovering a problem in the field after the software or hardware has been released more generally. Furthermore, the reputation of the company is improved by having fewer problems with the released software or hardware than competitors who utilize less thorough testing.
Software test engineers commonly test the functionality and behaviour of a program both pre and post launch. When performing testing, it is desirable to test out the software on a large number of devices and operating systems to ensure the product is ready for widespread sale for (and can be supported by) all types of computer system. A program which works well on one type of device may experience difficulties running on another type of device. The testing can therefore be a time consuming exercise. Accordingly, the test engineer may want to test multiple devices without having to physically interface with each System Under Test (SUT). Typically the same test will need to be executed a number of different times on the same operating system. Furthermore, when having to perform the same test on a number of different devices, the test engineer would ideally want to run the same sequence of steps without actually having to input each and every step for every test.
In the area of system administration, similar problems are also encountered. An IT professional will typically be called upon to implement a new program, upgrade or other such tasks throughout an entire network or system. In such instance, the administrator will frequently be required to visit each and every computer in order to perform the necessary tasks, and to verify the proper functioning thereof. This opportunity to access the computers has been made far more difficult with the advent of mobile systems and wireless communications, where many more of the computers connected through the network are not physically accessible at any given time.
In order to verify the performance of either software, hardware or a combination of the two, and regardless of whether the verification is being driven from the perspective of a manufacturer, developer, vendor, technical support, or internal maintenance within a single organization, this verification requires substantial interaction with the computer.
In an attempt to reduce the overhead associated with software debugging, a number of persons have developed methods for testing software by using a computer program. Many of these methods send information directly to the software or hardware, thereby bypassing the normal input channels and operations. Representative of the computer testing methods are U.S. Pat. No. 5,371,883 to Gross et al; U.S. Pat. No. 6,046,740 to LaRoche et al; U.S. Pat. No. 6,026,236 to Fortin et al; U.S. Pat. No. 5,022,028 to Edmonds et al; U.S. Pat. No. 5,249,270 to Stewart et al; U.S. Pat. Nos. 5,321,838 and 5,333,302 to Hensley et al; U.S. Pat. No. 5,335,342 to Pope et al; U.S. Pat. No. 5,594,892 to Bonne et al; U.S. Pat. No. 5,881,230 to Christensen et al; U.S. Pat. No. 5,926,638 to Inoue; U.S. Pat. No. 5,669,000 to Jessen et al; U.S. Pat. No. 6,119,247 to House et al; U.S. Pat. No. 6,195,765 to Kislanko et al; U.S. Pat. No. 6,249,882 to Testardi; U.S. Pat. No. 6,282,701 to Wygodny et al; and U.S. Pat. No. 6,353,897 to Nock et al; and 2002/0,099,978 to Kraffert, the contents of each of which are incorporated herein for their teachings of the various methods and techniques associated with the control and operations associated with such systems.
Test programs are known to test the functionality of an SUT. Typically the test program is run upon a computing device or computing system that is remote from the SUT. The computer system running the test program is however in communication with the SUT so that the test program can interact with the SUT. The SUT may be, for example, a PC running a version of Microsoft Word™ upon a Windows 7™ operating system.
Test programs typically test an SUT by interacting with the SUT and validating the state of the SUT according to an input test description (also referred to herein as a script). Test descriptions may also be referred to as automated test descriptions. Test descriptions can take many forms including but not limited to text instructions, software in source code or binary form, work-flows in a diagrammatical form (such as a flow chart). Executing (or ‘running’) the test description through the test program allows the system under test to be tested automatically, without requiring a test engineer to provide input to the testing process, other than initiating it.
Some test programs that use automated test descriptions are known. One test program that helps software engineers automate the testing process is ‘EggPlant™’ by TestPlant™. The EggPlant™ software tool allows a user to create and subsequently execute an automated test description to test a large number of SUTs. This test program interacts and controls an SUT by receiving and analysing images of the SUT Graphical User Interface (GUI).
Test programs such as EggPlant™ that utilise GUI images operate by identifying expected image objects in a GUI image that relate to executable functions that the test description may wish to identify and interact with or indicate the status of the SUT. Once the expected image object has been identified in the GUI image, the test program description can move to the next step in the test. The identification of the expected image object is performed using image analysis. The image analysis searches the GUI image for the expected image object using an existing reference image that is similar or identical to an expected image object. When a match is found, the expected image object is identified. Examples of image objects may include: an image of a button on the GUI that when ‘clicked’ would open a dialogue box, or the presence of a particular graphical object that signified the completion of a particular action performed by the target program. The test program may use image analysis techniques to perform these comparisons.
Reference images are typically created when generating the test description. When generating the test description the user typically uses the test program in a ‘description creation mode’, to navigate an SUT. Typically the navigation involves manually testing a particular SUT. As the user performs the testing steps, the information about the steps is entered into the test description. The test description is typically created either manually and/or automatically by a test engineer using the test program. Where commands in the test description require the use of reference images as described above, the user creating the test description manually selects the desired portion of a GUI image (taken from the SUT being tested) using an image selection tool whereby the selected portion of the GUI image is saved as the reference image.
When the test description is completed and subsequently run automatically by the test program to test a further SUT, the same testing steps are performed upon the further SUT using the same saved reference images. This can cause issues when the further SUT is different to the SUT initially used to create the saved reference images.